The present invention generally relates to the Internet Protocol (IP), and more particularly to improved bit error resilience for an IP protocol stack based on a secure link layer, as well as a method and system for protecting header information in header compressed packets.
The Internet Protocol (IP) is the underlying network layer protocol for routing packets on the Internet and other similar networks. The Internet Protocol is an internetwork protocol, and provides a means for communication across linked networks. The linked networks that form the overall internetwork are normally referred to as subnetworks. Whereas frames are used for transmitting data on subnetworks, so-called IP datagrams are the “envelopes” for transmitting data across the internetwork. In general discussions, frames as well as IP datagrams are often referred to as packets. As the IP datagrams cross a subnetwork, they are normally encapsulated in the frames of that subnetwork, and upon arrival to a router, the datagrams are extracted from the frames and repackaged into the frames of the next subnetwork.
The two main schemes that have been adopted by the Internet community to encapsulate and transmit IP datagrams, i.e. IP packets, over point-to-point links are the Serial Line Internet Protocol (SLIP) and the Point-to-Point Protocol (PPP). While SLIP is the original protocol, PPP is the predominant framing protocol since it also works with other protocols such as the Internetworking Packet Exchange (IPX) protocol. For example, PPP is commonly used together with the High-level Data Link Control (HDLC) Protocol, and often for Internet connections over dial-up lines where PPP links are established between users and service providers.
Applications for IP-based networks generally access the network resources through two interfaces, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). Both of these protocols reside in the transport layer between the applications on the application layer and the Internet Protocol on the network layer. While TCP is a connection-oriented protocol with features for providing reliable delivery of data, UDP is a connectionless protocol without the reliability present in TCP. UDP gives applications a direct interface to the Internet Protocol and the ability to address a particular application process running on a host without establishing a connection session, as is required by TCP. In many cases, when an entire transmission can be effectuated in just a few UDP packets, UDP provides for much more efficient communication compared to TCP. Establishing a TCP connection session would just take too much time in proportion to the data to be sent. In addition, applications and protocols designed for delivering delay-sensitive real-time data such as voice or video typically use UDP as their transport layer protocol. If a packet of voice or video is lost, retransmission is usually not practical since the retransmitted information would be out of synchronization with the current data. Consequently, for delay-sensitive real-time data, the acknowledgment-and-retransmission services offered by TCP has low practical value, and instead UDP is utilized.
To improve transmission efficiency in general, and for PPP links of low and medium speed in particular, different techniques for compressing the headers of IP/UDP and IP/TCP packets have been devised. For example, RFC 2507 and RFC 2508 of the Internet Engineering Task Force (IETF) specify Internet standards on IP header compression applicable to IPv4 headers and IPv6 base and extension headers, TCP and UDP headers, as well as encapsulated IPv4 and IPv6 headers. In particular, RFC 2507 and RFC 2508 The IETF RFC 2507 and RFC 2508 are hereby incorporated by reference.
Header compression reduces the negative impacts of large IP headers significantly, and allows efficient bandwidth utilization. Among other things, header compression reduces header overhead, and thus less bandwidth is required for the headers. It also reduces the packet loss rate for any given bit error rate, because fewer bits are sent per packet compared to full header packets.
The key feature that allows efficient header compression is that in a packet flow most header fields are identical in consecutive packets. For simplicity one may think of a packet flow as all the packets sent from a particular source address and port to a particular destination address and port using the same transport protocol. A basic principle for compressing the headers of a packet flow is to send a packet with a fall header and establish an association between the non-changing fields of the full header and a context identifier (CID), a small unique number also carried by compressed headers. The association between the non-changing fields and the context identifier is typically implemented in a header compression table in which the non-changing fields of the full header are stored as a compression state. The CID identifiers in the compressed headers of subsequent packets are used to find the corresponding compression state in the header compression table to use for decompression. Any change in a header field that is not expected to change will cause the compressor to send a new full header to update the compression state for the packet flow. In addition to the CID identifiers, the compressed headers may also include incremental changes to various header parameters.
In order to alleviate the problem of incorrect decompression, full headers are typically sent occasionally to refresh the compression state, and according to IETF RFC 2507 each new version of the compression state for a given CID is identified by a generation number. In RFC 2507, a generation number is carried by each full header that refreshes a compression state, and the compressed headers carry the generation number of the compression state that was used for compressing the headers. When the decompressor finds that a compressed header carries a generation number other than the generation number of the compression state for that packet flow, the compression state is out of date and the header compressed packet must be discarded or stored until a new full header establishes a correct compression state.
In RFC 2508, the problem of incorrect decompression is solved by a sequence counter and peer signaling.
FIG. 1 illustrates a full UDP header with CID and generation association as well as a corresponding compressed header based on the CID and generation fields according to RFC 2507. The gray fields of the full header are stored as the compression state. The UDP checksum is normally included in the compressed header as a safety precaution.
Without header compression, a bit error only affects the packet actually containing the bit error. However, when header compression is applied and a bit error occurs in a full header, a single bit error may cause the loss of a large number of subsequent header compressed packets. This is because the bit error will propagate into all subsequent compressed headers that are expanded using the compression state established by the faulty full header. If the link layer protocol utilizes a strong checksum, such bit error propagation is prevented because frames with bit errors will be discarded before they reach the decompressor. As noted in the article Low-loss TCP/IP header compression for wireless networks by Degermark et al., Wireless Networks 3 (1997), pp. 375–387, this generally means that IP header compression requires the use of a secure link layer protocol with a strong checksum.
The bit-error resilience, also referred to as bit-error tolerance, of an ordinary IP protocol stack (IPv4 or IPv6) is normally based on a secure link layer protocol such as the High-level Data Link Control (HDLC) protocol. FIG. 2 is a schematic overview of a UDP/IP protocol stack based on a HDLC link layer. In this example, IP header compression in the header compression (HC) sublevel of the link layer is used for improving the transmission efficiency of the link. FIG. 2 also illustrates the existing checksums in a UDP/IP stack.
The standardized secure link layer protocols of today generally have a simple error detection mechanism with a checksum that covers the entire frame. As can be seen in FIG. 3, which illustrates the different headers of the UDP/IP protocol stack of FIG. 2 and the coverage of the existing checksums in more detail. The HDLC protocol normally has a 16 or 32 bit checksum that covers the entire HDLC frame except for the start and stop flags. If a bit error occurs anywhere in the frame part covered by the HDLC checksum, the corresponding packet will simply be discarded at the receiving end when the checksum error is detected. The other available checksums, on the UDP level and for the IPv4 header, would be redundant in this case. They are only used for extra protection to guarantee that the application packet reaches its correct destination.
However, for many IP-based applications, especially those involving delay-sensitive real-time data, such as voice or video, the checksum error detection mechanism of the secure link layer is not particularly appropriate and generally leads to severe degradations of the application quality. In particular, for lossy links with high bit error rates (BER), such as radio or microwave links, or even low quality copper cables, far too many packets will be discarded because of the strong checksum error detection of the link layer protocol. On the other hand, header compression techniques used for improving the transmission efficiency, especially for links of low and medium speed, strongly require the use of a secure link layer.
In view of the above conflicting requirements on the link layer, there seems to be a general need to devise a new strategy for improved bit error resilience, especially for low and medium speed links with relatively high bit error rates.